Automatic data processing systems are known. Such systems often accept data from a variety of sources, process such data into desired results and either store the data for future use, or output the data in hardcopy form.
Data processing systems are often used by far-flung manufacturing and research organizations for a multitude of purposes. In a manufacturing context, a sales organization of a company may coordinate and track sales efforts through software applications (e.g., order-entry systems) developed for such purposes.
Data generated for sales tracking by a sales branch of an organization may be retrieved by other parts of the same organization and used for other purposes. For example, the data on sales may be provided as an input to a software application functioning as a manufacturing model which may order raw materials and schedule manufacturing activities. The price of raw materials and labor may be fed into a profitability model that may be rippled back to sales as a means of adjusting price margins. Product specifications associated with a particular sale may be entered into the data processing system and used to adjust the type of raw materials ordered and the processes used in the manufacture of the finished product.
The type of raw materials ordered for a particular manufactured product may be tracked and an overall defect rate calculated with the particular type of raw material used. In summary, data entered into a data processing system may be operated upon by numerous subroutines to generate a host of end results. Further, the processes using the data may be executed sequentially, or entirely randomly.
Similarly a call processing system used in a telecommunications context (e.g., a public switch telephone network (PSTN)) may call numerous subroutines for processing raw data. For example, a call placed by a calling party to a called party may be tracked at different points of call setup by any of a number of identifiers. The identifiers may include the number called, an identifier of the calling party (e.g., ANI number) or a randomly generated call transaction number associated with the call.
When the call request is first received by a local telephone switch by the calling party, a billing file must be created or updated based upon a number of factors including the service rate of the calling party, the identity of the called party, time of day, etc. Once a billing file is created, a controller of the local switch (by reference to the called number) may determine how to establish a connection with the called party. A call transaction file may be created and delivered along with the call to the call destination.
For example, where the call destination is a service organization of a corporation and the call may be handled by any of a number of agents of the organization, the call may be first delivered from the PSTN to a private branch exchange (PBX) or automatic call distributor (ACD) of the organization. Where the ACD has many call destinations within the ACD, the called number may be extracted from the delivered call transaction file and used to route the call into a call queue for the called number. Where the called number has a range of values (i.e., indicating agents with different qualification levels), the called number may be examined to determine a qualification level of a agent to be assigned to the call.
While in a call queue of the ACD, the identifier of the calling party (i.e., the ANI number) may be used by a data processing system of an ACD to identify the calling party as an existing customer, or a new customer. If the calling party is an existing customer, the data processing system may retrieve a customer file for display at a terminal of the selected agent at the same time the call is delivered to the agent.
In an ACD with agents in diverse locations, the identity of the calling party may be examined to identify and deliver the call to an agent that is geographically near the calling party. Where the calling party has attempted to block transmission of the ANI number, the data processing system will want to notify a selected agent of such attempt.
In summary, many different software applications may operate upon the same data at the same or at any particular stage of call progression. In addition, when many different calls are being processed concurrently, the same applications may be called repeatedly in close succession. In calling a software application, an ACD controller may often search through a list of applications (e.g., state machine tables) sequentially in the same order each time until it finds a particular application.
Often the software applications and related supporting software are ordered in a memory unit based upon a point in time (e.g., year and month) when the application was developed, with the newest application last. Even where the order of stored applications is changed based upon an attempt to place more frequently called applications first, the use of such applications may still change over time, or dynamically, based upon time of day. Where the number of applications that may be called is large, considerable time may be spent searching for the proper application. Accordingly, a need exists for a method for reducing the time spent looking for software routines based upon time-of-day and experience.